Method of broadcasting multimedia content via distribution network

ABSTRACT

The invention proposes to divide a content to be transmitted via a network into a set of slices and to generate a set of files from this set of slices. The slices (or the files) are encrypted before downloading in such a way that the client cannot use the slice (or the file) before having acquired the associated decryption key. The invention thereby allows protecting a downloaded content on a slice-by-slice basis (or on a file-by-file basis) rather than protecting a downloaded content as a whole. The transmission (in download mode) between the server and the client is ruled by the HTTP protocol that is accepted by all firewalls and NAT. Consequently, the transmitted content is accessible for any client device that has access to the Web without restriction. Advantageously, the slices can be decoded independently of each other.

FIELD OF THE INVENTION

The present invention relates to a method of transmitting a multimediacontent to a client device. The invention also relates to a system, acontent server, and a client device specifically designed to implementsuch a transmission method.

The invention has interesting applications for the transmission of paycontent to client devices via the Internet, in particular for thetransmission of live content (live events, live shows, broadcast TVprograms and the like).

BACKGROUND OF THE INVENTION

European patent application n°1 187 423 describes methods oftransmitting on-demand information whose content varies with time, likemusic or video. In particular, it describes a so-called bufferingdistribution method that consists in dividing a single piece of contentinto a plurality of files and in downloading the content file by file,starting from the first file. This buffering distribution method isdescribed as providing the advantage of reducing the waiting time beforestarting playback (while part N is being downloaded, part N-1 can beplayed).

One of the objects of the invention is to propose improvements for sucha distribution method.

SUMMARY OF THE INVENTION

This is achieved with a system as defined in claims 1 to 3, a contentserver as defined in claims 4 to 7, a client device as defined in claims8 and 9 and a method as defined in claim 10.

A system according to the invention comprises:

-   -   a source for acquiring a multimedia content,    -   an encoder for encoding said multimedia content,    -   a slicer for slicing said encoded multimedia content into at        least one set of slices, and for providing at least one set of        files from said at least one set of slices, said slicer        implementing an encryption algorithm, such that at least the        slice contained in a file cannot be used without a decryption        key associated therewith,    -   a distribution network,    -   an access provider for providing a client device with an access        to said distribution network,    -   a content server linked to said distribution network and having        access to said set or sets of files for downloading at least one        of said files to said client device via said distribution        network upon reception of a request from said client device, and    -   a key server linked to said distribution network for providing        said client device with the decryption key or keys that are        associated with the downloaded files.

With the invention, the content is divided into a set of slices and afile is generated for each slice. The slices (or the files) areencrypted before downloading in such a way that the client device cannotuse the slice (or the file) before having acquired the associateddecryption key. The invention thereby allows protecting a downloadedcontent on a slice-by-slice basis (or on a file-by-file basis) ratherthan protecting a downloaded content as a whole.

This is advantageous for the following reason: when the downloadedcontent is protected via encryption, the decryption key is usuallyprovided after the download has been completed so as to make sure thatthe download was successful (thereby eliminating the risk that theclient pays for something that he will eventually not receive) and toavoid that the client may watch the content and disconnect before beingcharged. Protecting the slices (or the files) one by one (or group bygroup) allows the client to decrypt and therefore start playing thecontent before all the files are downloaded while making sure that theclient received correctly what he paid for, and cannot use what he didnot pay for.

With the invention, the client does not have to pay for the wholecontent beforehand. Payment is progressive as playing goes along. Theclient can start playing a content and disconnect before the wholecontent has been downloaded if he wishes to do so. In such a case hewill only pay for what he eventually received.

The invention safeguards the interests of both the content provider andthe client.

According to the invention, the file-based content is downloaded fromthe content server to the client device via a point-to-point connection.On IP networks, point-to-point connections are usually ruled by the HTTPprotocol (Hyper Text Transfer Protocol, defined in the RFC2616 of theIETF). The HTTP protocol is the basis for the World Wide Web andtherefore has the great advantage of being accepted by all firewalls andNetworks Address Translators (which is not the case with the RTP/UDPtransport protocol). This means that the transmitted content will beaccessible for any client device having access to the World Wide Webwithout restriction. Another advantage of using a downloadingdistribution mode is that it is highly reliable.

However, using a downloading distribution mode of the type described inEuropean patent application n°1187423 has the drawback that all fileshave to be transmitted, starting from the first file. With such adownloading distribution mode, the client cannot access the content atrandom. Transmission of a live content (that is, a content madeavailable in real-time, like live events, live shows, broadcast TVprograms, . . . ) cannot be achieved.

In an advantageous embodiment of the invention, the slices are generatedin such a way that they can be decoded independently of each other. Thismeans that the client does not need to receive the content from itsbeginning. It can start receiving the content from any slice. When aclient sends an initial request directed to a live content, he willreceive either the previous file (which means he will receive slightlyoutdated information) or he will have to wait for the next file to getready.

With the invention, it is also possible to download one file only, uponreception of a request by a client device. This is advantageous forcertain applications, for example, to allow clients to get a quickoverview of the results during championships.

When a plurality of files is to be downloaded, the files can be eitherfetched one by one by the client device or sent one by one by thecontent server upon reception of an initial request. In practice, it isnot certain that all client browsers will support reception of severalfiles in response to one single request. Therefore, it will usually bepreferred that the client device fetches the files one by one (i.e.sends a fetching request for each file to be downloaded). The clientdevice can be designed specifically so as to automatically send thefetching request at the appropriate time. Alternatively, the contentserver can send a document to the client device, said document causingthe client device to repetitively send a fetching request.Advantageously, said document comprises an instruction for the clientdevice to send a subsequent fetching request a certain amount of timebefore the end of the playback of the previous file. In such a way, itis ensured that the next file will reach the client device early enough,and that the client will not experience any gap in the playback process.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of the invention are further described withreference to the following drawings:

FIG. 1 is a schematic representation of a first example of a systemaccording to the invention,

FIG. 2 is a schematic representation of a second example of a systemaccording to the invention,

FIG. 3 is a schematic representation of a set of files generated by aslicer according to the invention,

FIG. 4 is a first example of a protocol to be implemented for the clientdevice to acquire the decryption key associated with a specific file,

FIG. 5 is a second example of a protocol to be implemented for theclient device to acquire the decryption key associated with a specificfile,

FIG. 6 is a block diagram of a first example of a method according tothe invention for downloading a live multimedia content,

FIG. 7 is a block diagram of a second example of a method according tothe invention for downloading a live multimedia content.

DESCRIPTION OF EMBODIMENTS

FIG. 1 is a schematic diagram of a first example of a system accordingto the invention. The system of FIG. 1 comprises:

-   -   a source 1 for acquiring a multimedia content;    -   an encoder 5 for encoding a received multimedia content,    -   a slicer 6 for slicing an encoded multimedia content into a set        of slices and for providing a set of files, each file containing        a slice of said encoded multimedia content, said slicer        implementing an encryption algorithm, such that at least the        slice contained in a file cannot be used without a decryption        key associated therewith,    -   a content server 8 having access to said files,    -   a distribution network 10, the content server 8 being linked to        the distribution network 10,    -   an access provider 12 for providing a client device 14 with an        access to the distribution network 10,    -   a key server 15 linked to the distribution network 10 for        providing the client device 14 with the decryption key or keys        that are associated with the downloaded files.

In the system of FIG. 1, the source 1, the encoder 5 and the slicer 6may be physically located in one or in several devices.

FIG. 2 is a schematic representation of a second example of a systemaccording to the invention. In addition to the elements described abovewith reference to FIG. 1, the system of FIG. 2 comprises:

-   -   a broadcasting system 16 for broadcasting the multimedia content        provided by the source 1; and    -   a receiver 17 for receiving the broadcast multimedia content,        and forwarding the received multimedia content to the slicer 6.

The client device 14 has (amongst other means not represented in FIG. 1)a communication unit 20 for transmission/reception to/from the accessprovider 12, a player 22 for playing an encoded multimedia content, anda display 24 for displaying a multimedia content. The client device 14may be either a mobile device (like a mobile phone), in which case thecommunication unit 20 is a radio communication unit, or a wired device(like a PC), in which case the communication unit 20 is a wiredcommunication unit. The distribution network 10 is typically theInternet network.

The broadcasting system 16 is, for instance, a satellite broadcastingnetwork and the receiver 17 is a satellite receiver. This is notrestrictive: any other broadcasting means could be used instead ofsatellite broadcasting means. The broadcast multimedia content may beany multimedia content that is transmitted and can be received by anumber of receivers including the receiver 17. The broadcast multimediacontent may be, for instance, a television program, a pre-recordedevent/program, a live event, etc. The encoder 5 is responsible forencoding the received multimedia content. The encoder 5 is compliantwith, for instance, one of the MPEG standards, or with H263.

The encoder 5 and the slicer 6 are either implemented in a single deviceor in two separate devices. In both cases, what is transmitted from theencoder 5 to the slicer 6 is an encoded video stream. Advantageously,this encoded video stream is transmitted from the encoder 5 to theslicer 6 over IP by using the RTP protocol. This is not restrictive. Byway of example, the transport layer of the MPEG-2 standard, known asMPEG-2 TS, could be used as well.

In practice, the files generated by the slicer 6 are stored in a storageunit 26 to which the content server 8 has access. The storage unit 26 isshared by the slicer 6 and the content server 8. The storage unit 26 maybe part of the content server 8 or can be located remotely.

The slicer 6 has the following functions:

-   -   a) It slices the encoded content generated by the encoder 5 into        a plurality of slices, where each slice comprises a given amount        of time of the encoded multimedia content.    -   b) It generates a file from each slice.    -   c) It implements an encryption algorithm, such that at least the        slice contained in a file cannot be used without a decryption        key associated therewith. This can be achieved by encrypting the        slice or encrypting the file. Encrypting the files has the        advantage of simplicity. Encrypting the slices is more complex.        However, it allows accessing the file information contained in        the file structure (for example, in the headers) at the client        side without having to decrypt the file first. By way of        example, the encryption algorithm used by the slicer 6 is AES        (Advanced Encryption Standard). Encryption is done by using an        encryption key. An associated decryption key is needed to        achieve decryption of the encoded entity (the slice or the        file). The key server 15 is responsible for delivering the        encryption key to the slicer 6 and the decryption key to the        client device 14.

The slicer 6 can generate a plurality of sets of files for the samemultimedia content. By way of example, when the slicer 6 generates aplurality of sets of files, a plurality of sets of slicing positions canbe used, each set of slicing positions being shifted in time as comparedwith the other sets of slicing positions. Generating a plurality of setsof files is advantageous because it allows reducing the delayexperienced by the client when he sends a request for a live content.

FIG. 3 is a representation of a set S_(i) of files F_(i,j) (j=1, . . . ,N) generated by the slicer 6 by slicing an encoded multimedia content atslicing positions T_(i,j) (j=1, . . . , N−1).

In an advantageous embodiment, the slices are generated in such a waythat they can be decoded independently of each other. In practice, anyencoded multimedia content generated by a multimedia encoder comprisesso-called Random Access Points (RAP). In order to produce slices thatcan be decoded independently of the others, the slicer 6 slices theencoded multimedia content in such a way that each slice starts with aRandom Access Point. For instance, when the encoder is compliant withthe MPEG-2 or MPEG-4 standard, the random access points are the I-framesof the MPEG-encoded multimedia content, and the slicing positions arechosen in such a way that the first frame of each slice is an I-frame.

Optionally, the size of the slices is adjustable. It may be identicalfor all slices or it may vary from one slice to another (for instance,the size of the slices may increase with time). The best efficiency isobtained with files that are relatively long because the more files aretransported, the more overhead due to file headers is obtained.

Each file generated by the slicer 6 is stored as a file in the storageunit 26. The storage unit 26 has to be “cleaned” on a regular basis toensure that there is room available for storing the newly generatedfiles. A way of cleaning the storage unit is to re-use file names on aregular basis. An alternative way is to use different file names foreach file, and to delete the aging files on a regular basis.

The content server 8 and the key server 15 are linked to thedistribution network 10. The client device 14 has access to thedistribution network 10 via the access provider 12. Typically, theclient device 14 can load, through the distribution network 10, a pagecontaining at least one link to one encoded multimedia content that thecontent server 8 offers to download. When a user clicks on said link, aninitial request R₀ directed to said encoded multimedia content is sentautomatically to the content server 8. There are several possible waysfor the content server 8 to handle the initial request R₀.

In a first embodiment, the content server 8 downloads a single file inresponse to the client request. This implementation can be used forspecific applications, for instance, for applications offering theclient to pick up information regarding a live event. It can also beused with a player 22 specifically designed to cause the client device14 to send the initial request R₀ repetitively.

In a second embodiment, the content server 8 downloads the files one byone as soon as they are ready at the server side. This embodiment hasthe advantage of being easy to implement. However, there is a risk thatcertain client browsers will not support reception of several files inresponse to one single request.

In a third embodiment, the content server 8 sends a document to theclient device 14 upon reception of the initial request R₀. This documentcauses the client device 14 to repetitively send a fetching requestdesignating the encoded multimedia content.

By way of example, the document sent by the content server 8 may be apage comprising an automatic refresh command. An example of such a pageis given below:

<html> <head> <META meta http-equiv=“Refresh” content=“134” ;url=‘http://www.yoursite.com/live2download.html’” </head> <embedsrc=“live2download.mp4” width=“240” height=“240”> </embed> </html>

Such a page causes the client browser to reload the file“live2download.mp4” every 134 seconds (which is the duration of a filein this example).

Alternatively, the document sent by the content server 8 may be astandard description of the multimedia content, said standarddescription being intended to be processed by the player 22 in astandard way. Such a description may be, for instance, an SMILdescription (SMIL is a W3C standard defining XML-based audio/video scenedescriptions). An example of such an SMIL description is given below:

<smil> <head> <layout> <root-layout width=“240” height=“240”background-color=“white”/> <region regionName=“im” left=“0” top=“0”width=“240” height=“240”/> </layout> </head> <body> <seq repeatCount =“indefinite” > <video id=“vid” src=“live2download.mp4” region=“im” /></seq> </body> </smil>

The effect of this SMIL document is to cause the player 17 to play thefile “live2download.mp4” repetitively. As a result, the client devicewill repetitively send fetching requests directed to the file“live2download.mp4”.

Advantageously, the SMIL document sent by the content server 8 comprisesa command indicating that the files have to be fetched some time inadvance (that is, some time before the end of the playback of theprevious file). This ensures that the next file will arrive at theclient device 14 in time so that the client will not experience a gap inthe rendering of the multimedia content. An example of an SMILdescription having such a command is given below:

<smil> <head> <layout> <root-layout width=“240” height=“240”background-color=“white”/> <region regionName=“im” left=“0” top=“0”width=“240” height=“240”/> </layout> </head> <body> <seq repeatCount =“indefinite” > <video id=“vid” src=“live2download1.mp4” region=“im”clipBegin = “0s” dur = “25s” /> <par> <prefetch src=“live2download2.mp4”mediaTime =“5s” /> <video id=“vid” src=“live2download1.mp4” region=“im”clipBegin = “25s” /> </par> <video id=“vid” src=“live2download2.mp4”region=“im” clipBegin = “0s” dur = “25s” /> <par> <prefetchsrc=“live2download1.mp4” mediaTime =“5s” /> <video id=“vid”src=“live2download2.mp4” region=“im” clipBegin = “25s” /> </par> </seq></body> </smil>

This document is written for slices containing 30 s of content. Itcauses the player 17 to execute the following operations in sequence:

-   -   a) playing the first 25 s of a first source        (live2download1.mp4);    -   b) playing the last 5 s of the first source and in parallel        fetching the first 5 s of a second source (live2download2.mp4);    -   c) playing the first 25 s of the second source (which can be        done without delay since the first 5 s have been pre-fetched).        Using two different sources is an implementation trick. The        content server 8 must be designed to recognize that the first        and the second source correspond to the same encoded multimedia        content.

When the content to be downloaded is a live content, the server has toselect which file to download upon reception of the initial request R₀or upon reception of the fetching requests. The content server 8 caneither select the most recent file or the first file to get ready. Theconsequence of selecting the most recent file is that the client willreceive outdated data. The consequence of selecting the first file toget ready is that the client will have to wait a certain time beforegetting a response. In FIG. 2, an arrow A indicates the reception of theinitial request R₀ by the content server 8. If the downloaded file isfile F_(i,1), the client will not experience any delay; however he willreceive data that will be late by a time equal to a_(i,1). If thedownloaded file is file F_(i,2), the client will not receive outdateddata; however, he will experience a delay equal to b_(i,2).

When the download of a file is achieved, the client device 14 has toacquire the associated decryption key in order to be able to play thecontent of the file. Two ways of acquiring this decryption key will nowbe described with reference to FIG. 4 and FIG. 5, respectively.

In FIG. 4, the client device 14 sends an acknowledgment 30 to thecontent server 8 indicating that the download was successfullycompleted. Upon reception of the acknowledgement 30, the content server8 sends a notification 32 to the key server 15. Upon reception of thenotification 32, the key server 15 sends a message 34 containing theappropriate decryption key to the client device 14.

In FIG. 5, the client device 14 sends an acknowledgment 40 to thecontent server 8 indicating that the download was successfully completedand a request 42 to the key server 15. Upon reception of theacknowledgement 40, the content server 8 sends a notification 43 to thekey server 15. Upon reception of the notification 43 and the request 42,the key server 15 sends a message 44 containing the appropriatedecryption key to the client device 14.

The transmissions via the distribution network 10 are ruled by the HTTPprotocol.

A first example of a method according to the invention of transmitting amultimedia content M to a client device 14 will now be described withreference to FIG. 6. It comprises:

-   -   a step X1 of producing an encoded multimedia content E(M) from        the multimedia content M,    -   a step X2 of slicing the encoded multimedia content E(M) into a        set of slices Si,    -   a step X3 of encrypting a slice Si (or a group of slices) with        an encryption key KXi by applying an encryption algorithm X,        thereby providing encrypted slices X(Si, KXi),    -   a step X4 of providing a set of files Fi, where each file Fi        contains an encrypted slice X(Si, KXi),    -   a step X5 of downloading at least one of said files Fi to the        client device 14 via the distribution network 10 upon reception        of an initial request R₀ directed to the multimedia content M        from the client device 14.

A second example of a method according to the invention of transmittinga multimedia content M to a client device 14 will now be described withreference to FIG. 6. It comprises:

-   -   a step X10 of producing an encoded multimedia content E(M) from        the multimedia content M,    -   a step X20 of slicing the encoded multimedia content E(M) into a        set of slices Si,    -   a step X25 of providing a set of files Fi, where each file Fi        contains a slice Si,    -   a step X30 of encrypting a file Fi (or a group of files) with an        encryption key KXi by applying an encryption algorithm X,        thereby providing encrypted files X(Fi, KXi),    -   a step X50 of downloading at least one of said files X(Fi,Kxi)        to the client device 14 via the distribution network 10 upon        reception of an initial request R₀ directed to the multimedia        content M from the client device 14.

These steps are implemented by way of specific hardware and/or softwarecomprised in one or several devices. For instance, steps X1 and X10 areimplemented by the encoder 5, steps X2, X3, X4 and X20, X25, X30 areimplemented by the slicer 6, and steps X5 and X50 are implemented by thecontent server 8.

With respect to the described network, server, system, slicer, clientdevice, and downloading method, modifications or improvements may beproposed without departing from the scope of the invention. Theinvention is thus not limited to the examples provided.

File transfer protocols other than HTTP may be used (for example, FTP).

The content server and the key server may be the same physical entity.The encryption may be either applied to the slices or to the files. Theencryption key and the associated decryption key may be different oridentical, depending on the encryption algorithm that is used.

Use of the verb “comprise” and its conjugations in the description andin the claims does not exclude the presence of elements or steps otherthan those stated in the description and in the claims.

Use of the article “a” or “an” to designate an element or a step doesnot exclude the presence of a plurality of such elements or steps.

1. A system comprising at least: a source that acquires a multimediacontent]; an encoder that encodes said multimedia content; a slicer thatslices said encoded multimedia content into a plurality of slices,wherein each of the slices is decoded independently, and generates afile from each of the slices, said slicer implementing an encryptionalgorithm, such that the slice contained in the file cannot be usedwithout a decryption key associated therewith]; a distribution network;an access provider that provides a client device with an access to saiddistribution network; a content server linked to said distributionnetwork and downloading said encoded multimedia content on afile-by-file basis to said client device via said distribution networkupon reception of a request from said client device; and a key serverlinked to said distribution network that provides said client devicewith the at least one decryption key associated with the at least onedownloaded file.
 2. The system of claim 1, wherein the decryption key isprovided to said client device upon successful downloading of the fileassociated with the decryption key.
 3. A content server having access tofiles generated by slicing an encoded multimedia content into aplurality of slices, wherein each of the slices is decoded independentlyand the files are generated from each of the slices by implementing anencryption algorithm such that the slice contained in a file cannot beused without a decryption key associated therewith, said content serverhaving means for downloading said encoded multimedia content on afile-by-file basis to a client device upon reception of a request fromsaid client device, and means for sending a notification to a key serverupon successful downloading of a file to said client device so that saidkey server provides said client device with the decryption keyassociated with said file.
 4. A content server having access to filesgenerated by slicing an encoded multimedia content into a plurality ofslices, wherein each of the slices is decoded independently and thefiles are generated from each of the slices by implementing anencryption algorithm such that the slice contained in a file cannot beused without a decryption key associated therewith, said content serverhaving means for downloading said encoded multimedia content on afile-by-file basis to a client device upon reception of a request fromsaid client device, wherein said downloading means comprise: means forsending a document to said client device upon reception of said request,said document causing said client device to repetitively send a fetchingrequest designating said encoded multimedia content; means for selectingwhich file is to be downloaded upon reception of said fetching requestsfrom said client device; and means for downloading the selected file. 5.A client device having: means for connection to a content server, saidcontent server having access to files (generated by slicing an encodedmultimedia content into a plurality of slices, wherein each of theslices is decoded independently and the files are generated from each ofthe slices by implementing an encryption algorithm, such that the slicecontained in a file cannot be used without a decryption key associatedtherewith, said content server downloading said encoded multimediacontent on a file-by-file basis; means for repeatedly sending to saidcontent server a request directed to said encoded multimedia content;means for receiving one of said files in response to each request; meansfor acquiring the decryption key associated with each file; and meansfor decrypting and playing said files.
 6. The client device of claim 5,further comprising: means for sending a subsequent request before endingplayback of a current file.
 7. A method of transmitting an encodedmultimedia content to a client device, said method comprising the stepsof: encoding a multimedia content; slicing said encoded multimediacontent into a plurality of slices, wherein each of the slices isdecoded independently and a file is generated from each of the slices byan encryption step, such that the slice contained in a file cannot beused without a decryption key associated therewith; and downloading saidencoded multimedia content on a file-by-file basis to said client devicevia said distribution network upon reception of a request from saidclient device.
 8. The system of claim 1, wherein payment for saidmultimedia content is progressive, limited to only downloaded files ofsaid multimedia content.
 9. The content server of claim 3, whereinpayment for said multimedia content is progressive, limited to onlydownloaded files of said multimedia content.
 10. The client device ofclaim 5, wherein payment for said multimedia content is progressive,limited to only downloaded files of said multimedia content.
 11. Themethod of claim 7, wherein payment for said multimedia content isprogressive, limited to only downloaded files of said multimediacontent.
 12. The content server of claim 4, wherein payment for saidmultimedia content is progressive, limited to only downloaded files ofsaid multimedia content.